The Internet allows users to search the massive quantities of information stored in computers located all over the world, retrieve data and place it on their own computers. The Internet has been around, in various forms, since 1969. However, until the World Wide Web (WWW) was launched in 1993, computer users had to utilize cumbersome methods with cryptic commands to transfer or receive information. The Web, on the other hand, is a user-friendly graphical interface that lets users simply point and click a mouse to effortlessly navigate the Internet.
A standard naming convention has evolved on the Web known as a Uniform Resource Locator (URL). The URL is a physical address of an object which is retrievable using network protocols such as Hypertext Transfer Protocol (HTTP) and File Transfer Protocol (FTP). URLs are mostly used to identify resources on the Internet such as documents. In most cases, the URL syntax is straight forward, containing a document path, either absolute or relative, to a certain starting pointer. A typical URL has the following form: "http://the-tech.mit.edu/weather/ . . . " The first part of the URL, before the colon, specifies the access protocol over the Internet. In this case, http means "HyperText Transfer protocol," the protocol used by web servers. The second part of the URL names the location (computer) to access. Generally the first words between the slashes indicate the name of the computer where the information is housed; and the remaining words identify directories and file names. A number of techniques have been employed to extend the capability of a URL. One prior art technique discloses a method of encoding information in a File Transfer Protocol (FTP) Uniform Resource Locator (URL), which is sent to a World Wide Web (WWW) browser in order to access data on a machine remotely connected to an FTP Server. Access to the WWW via a web browser has become ubiquitous, both at home and in the corporate environment. One feature of the web browser is the ability to get and put files on an FTP Server. The web browser supports the ability to pass a Userid and password to the FTP Server and implements the function of an FTP client to access these files and traverse directories. A normal connection to an FTP server from a web browser uses an FTP URL and is of the form: //userid:password@hostname. In order to trick the Web browser into instructing the FTP Server that an APPC File Transfer Protocol (AFTP) connection is needed, and provide it with destination, Userid, and password, a technique is used to differentiate it from a normal FTP connection. The technique combines a System Network Architecture (SNA) destination and Userid into the FTP Userid field and prefix each with a plus "+" sign. For example: ftp://+aftpserv+Userid+password@hostname. The Userid and password strings were passed directly to the FTP Server which was able to recognize the plus sign "+" and interpret the data as the SNA destination "aftpserv", Userid and password.
Another prior art solution extends the capability of URLs by allowing the mapping of a protocol request to Uniform Resource Locators. When a URL is used to identify documents, the URL syntax is straight forward because it contains the document path to a certain starting point. URLs to identify protocol requests, however, have a rather complex mapping. One method uniquely maps a protocol request to a URL and vice versa. Such a mapping is compliant with the standard URL syntax and can thus be handled by conventional HTTP servers and Web browsers. The URL is composed of five elements: http://&lt;host&gt;/&lt;protocol&gt;/&lt;operation&gt;/&lt;context&gt;?&lt;parameters&gt;, wherein &lt;host&gt; identifies the host where the HTTP server runs, &lt;protocol&gt; specifies the protocol operation, &lt;operation&gt; specifies the protocol operation, &lt;context&gt; specifies the context to use, if any and &lt;parameters&gt; contains the operation parameters. While each of the previously described methods have extended the functions of URLs, none provides the ability to specify local or remote computers containing a Java Beans repository.
Java Beans is an architecture and platform-neutral Application Programming Interface (API) for creating and using dynamic Java components. Java Beans and their common properties and functions are described in detail in the text, "Java in a Nutshell", 2nd. Edition, David Flanagan, O'Reilly and Assoc. Inc., 1997. Java Beans enhance the Java platform by allowing richer, more dynamic interaction. Java Beans allow developers to define independent components that can be used and re-used in a variety of combinations to compose new applications inside a variety of browser and non-browser environments. Java Beans components can be GUI widgets, non-visual functions and services, applets and more full-scale applications. Each of these components can be built by different developers at separate times.
Java employs a platform independent file format that concatenates and compresses a set of Java classes, image, audio and data files into one file called a JAR (Java Archive) file. One of the main attributes of the JAR file design is to reduce the number of HTTP (HyperText Transfer Protocol) connections that need to be opened, thus reducing download times. The file format is the popular ZIP format and can be used as a general archiving tool. Java Beans can be moved around in "bulk" using the JAR file. Current implementations of URLs are unable to specify local and remote Java Beans repositories and repository sub-elements.
The Java Development Kit (JDK), manufactured by Sun Microsystems, Inc., provides a Java.net package which contains a class called URL that permits programs to represent a URL address. Programs can interact with the Internet to find resources. Java's Java.net Class URL removes the requirement for programs to provide string parsing of URLs by returning host name, file name, and other information. While the Java.net Class eases access to the Internet, a general URL format has not evolved for specifying Java Bean repositories and repository sub-elements.
Consequently, it would be desirable to provide a method and apparatus for extending uniform resource locators so that they are capable of specifying local and remote Java Bean repositories and repository sub-elements.